-20- 



RB MARKS 

The Examiner has rejected Claims 1-3, 12-18, 27-30, and 91-92 under 35 U.S.C. 
101 as being directed toward non-statutory subject matter. Applicant has clarified the 
claims to include a computer program product "embodied on a tangible computer 
readable medium" in order to avoid such rejection 

The Examiner has objected to Claim 29 due to an informality. Such objection is 
deemed moot in view of the correction of Claim 29 hereinabove. 

The Examiner has further rejected each of the claims on the grounds of non- 
statutory obviousness-type double patenting as being unpatentable over Claims 1-21 of 
U.S. Patent No. 7, 107,574. Applicant asserts that such rejection is overcome in view of 
the filing of the terminal disclaimer submitted herewith. 

The Examiner has rejected Claims 1-3, 12-18, 27-33, 42-48, 57-63, 72-78, and 
87-92 under 35 U.S.C. 102(e) as being anticipated by Harvey et al. (U.S. Patent 
Publication No. 2006/01 90575). In addition, the Examiner has rejected Claims 1.-3 , 12- 
18, 27-33, 42-48, 57-63, 72-78, and 87-92 under 35 U.S.C 103(a) as being unpatentable 
over Uszok et at (U.S. Publication No. 2004/0205772) in view of Kouznetsov et al. (U.S. 
Patent No. 6,93 1 ,546), Applicant respectfully disagrees with such rejections. 

With respect to the 35 U.S.C 102(e) rejection of the independent claims, the 
Examiner has relied on the following excerpts from the Harvey reference to make a prior 
art showing of applicant's claimed "matching code to match each complex data type with 
an associated execution process available to said destination computer" (see this or 
similar, but not necessanly identical language in the independent claims). 

V M 0 0551 In response, based on the device's unique identifier, 
Configuration Server 116 retrieves one of the configuration 
templates 210 that is associated, with the device 114. The 
retrieved template is parameterized. Pa caiaeter values are 
resolved by retrieving specific; values rhroia Directory 110, or 
another repository, that correspond to the parameters. As a 
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result, a stream ox file of format configuration information 

is created and potentially stored. -> dPL i r ?J or;. -it - on • ospns^. 
one or more XML tags and attributes that contain one or more CLI 
commands that, represent a new device configuration. Each element 

<oord:ig> X.M1 tag and each device CLI ccsbki nb as embedded in a 
<cli> XML tag. The specific tags set forth herein are not 

squired; f tiona - sr;t ' f ferent name may 

be used." {emphasis added; 

w (00661 In push mode, configuration data can be pushed to the 
device 114 in the form of an event. , device > 

subscribes to a * ^ e * * -t.v td-t ^ >t 5 i- 

by event service 120. In this arrangement, XML format 
configuration information is sent as a payioad of an evens using 
the Event Gateway IIS. Push mode may be used to send identical 
configuration in formation to multiple devices, akin to a 
broadcast." {emphasis added) 

* 10067] In pull inode, Configuration Agent 200 pulls event 
information from a Web server using an HTTP GET request on 

to a particular event, it is desirable to cause the device to 
load a nev/ or updated configuration, or. when identical 
information cannot be sent to multiple devices, e.g., due to 
differences in the content of the information." {emphasis added) 



Applicant respectfully points out that the above excerpts relied on by the 
Examiner merely teach that the "Configuration Server 1 16 retrieves one of the 
configuration templates 210 that is associated with the device," that the "retrieved 
template is parameterized,"' and that "a stream or file of XML format configuration 
information is created and potentially stored." Additionally, the above reference citations 
teach that ^configuration data can be pushed to the device 114 in the form of an event" 
and that "Configuration Agent 200 pulls event information from a Web server." 



However, the retrieval and parameterization of a configuration template, the 
creation and storag e of XML configuration information, and the pushing and pulling of 
configuration data does not even suggest "matching code to match each complex data 
type with an associated -sj^ejufioiijgrocess" (emphasis added), as claimed by applicant. 



Additionally, the Harvey reference teaches that "[w]eb server 206 delivers XML 
encoded configurati on information from the server to the Configuration Agent 200" 
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(paragraph [0058]) and that ''Configuration Agent 200 carries out a parsing and checking 
process on the received XML. configuration information" in order to "[determine] 
whether the XML, information is well-formed" and "verify that it has received all the 
XML configuration information" (paragraph [0059]), as well as to perform a "CLI syntax 
check" (paragraph [0060]). However, parsing in order to check the received XML 
configuration and syntax, as in Harvey, does not teach "matching code to match each 
compjt datatype with an st tedt eaii y cess available to said destination 
computer" (emphasis added), as claimed by applicant. 

With respect to the independent claims, the Examiner has further relied on the 
following excerpts from the Harvey reference to make a prior art showing of applicant's 
claimed "triggering code to trigger processing by the or each execution process 
associated with a complex data type within said operation specifying XML data" (see this 
or similar, but not necessarily identical language in the independent claims). 

,v ( 00541 when the device 114 is powered-up at customer premises 
112, the device connects to Configuration Server 116 by 
establishing a TCP/IP connection . The device issues an HTTP get 
recjuesfc to Web server 206 of Configuration Server 116. To 

uniquely identity itself to the configuration Server 116 and to 
the vvefo server, the device 114 provides its token as a unique 
Identifier.' I emph asis added ) 

w [0064] ---Partial Configuration" 

Applicant respectfully notes that the above excerpts merely teach that the "device 
issues an HTTP get request to Web server 206 of Configuration Server 1 1 6" and 
"provides its token as a unique identifier." Issuing an "HT TP get request" and sending a 
"token as a unique identifier," as in Harvey, fails to even suggest ''triggering code to 
trigger processing by the or each execution process associated with a complex data type 
within said operation specifying XML data" (emphasis added), as claimed by applicant. 

With respect to the independent claims, the Examiner has further relied on the 
following excerpt from the Harvey reference to make a prior art showing of applicant's 
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daimed technique "wherein said execution process maps configuration data specified 
within said operation specifying XML, data to a configuration data store of said 
destination computer, wherein said configuration data store is one of. a Windows 
Registry entry; an INI file; a DAP! store; and a database entry" (see this or similar, but 
not necessarily identical language in the independent claims). 

i > 2, r t ■> 

cable .arid plugs in the network device 114. The cable installer 
does :k' ! . have any v * " ,u;e of the network device 114. The 

device 114 is preprogrammed with ox discovers a token that 
uniquely identifies itself, e.g., a router hostname or MAC 
address. Upon power: up, the device 114 establishes a connection 
to Configuration Server 116. The device 114 identities itself, 
using the token, to the server end requests the configuration 
information that is held in Directory 110 for the device." 
{emphasis added) 

Applicant respectfully points out that the above excerpt merely discloses that "the 
device 1 14 establishes a connection to Configuration Server 1 16" and that the device 
"requests the configuration information that is held in Directory 1 10 for the device " 
However, "e ;t tbj is] p i„ J t.cot lectioj to [the] Configuration Server" and "ret)uest[ing] 
configuration information," as in Harvey, does not teach ma pping "configuration data 
specified within said operation specifying XML data to a configuration data store," much 
less a technique "wherein said execution process maps configuration data specified 
within said operation specifying XML data to a configuration data store of said 
destination computer, wherein said configuration data store is one of: a Windows 
Registry entry; an 1NJ file; a DAP! store; and a database entry" (emphasis added), as 
claimed by applicant. 

With respect to the independent claims, the Examiner has relied on paragraph 
[0055] (reproduced above), in addition to the following excerpt from the Harvey 
reference, to make a prior art showing of applicant's claimed technique "wherein said 
operation includes returning result data from said destination computer to said source 
computer in dependence upon said operation performed by said execution process," as 
well as applicant's claimed technique "wherein said result data includes data specifying 



-24- 



existing configuration data of said destination computer and "wherein said execution 
process maps existing configuration data of said destination computer stored within said 
configuration data store oi h , • imp ter to said result, data to be returned to 
said source computer" (see this or similar, but not necessarily identical language in the 
independent claims). 



"(0056i Configuration Server 116 then checks whether the XML 
configuration inf orraation is valid 

Document Type Definition i DTD } that defines a grammar with which 
the ' , . * -> i. Th *■ > be 

carried out using a conventional XML parser, or an XML validation 
parser, of which several are commercially available. Such 
•'ifneckin.g may also involve testing whether the XML configuration 
intonation constitutes well- formed XML text, and syntactically 
cortect XML test. Determination of whether the XML in£ ormatioo is 
forms j. ( t Jtiori inforsiatioi 

checking at this stage involves checking the syntax of the XML 

text, without determining whether CLI strings contained within 
XML tags of the XML text constitute syntactically correct CLI 
commands." (emphasis added) 



As mentioned above, applicant respectfully points out that the excerpts relied on 
by the Exami ner merely teach that the "Configuration Server 1 16 retrieves one of the 
configuration templates 210 that is associated with the device," that the "retrieved 
template is parameterized" and that "a stream or file of XML format configuration 
information is created and potentially stored" (paragraph [0055]). In addition, the 
excerpts also teach "checking the syntax of the XML. text" in order to" [check j whether 
the XML configuration information is valid in comparison to a specified Document Type 
Definition (DTD)." 



Howe\ ei the mere disclosure o i nd p s, jmUcn/mg a configuration 

template at the C : onfigurati on Server, in addition to creating and storing XML 
configuration information, and checl u u syntax of XMI text, as in Harvey, simply 
fails to dist k >t returning result data from said destinat i torn; ter i much less a 
technique "wherein said operation includes returning result data from said destination 
computer to said source computer in dependence upon said operation performed by said 
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execution process," or a technique "wherein said result data includes da 
existing xnflguratii 1 " >f s lesti nation compute 1 1 w k , lid executi( 
process map exist) • n j> fata of said destination computer stored within said 

configuration data store of said destination computer to said result data to be returned to 
said source computer" (emphasis added) is claim* lb; applicant CI earl) retrieving a 
configuration template at the Configuration Server and storing configuration information, 
as in Harvey, simply fails to even suggest "returning result data," in the manner as 
claimed by applicant. 

With respect to the independent claims, the Examiner has relied on paragraphs 
[0055] and [0056] (cited above), in addition to the following excerpt from the Harvey 
reference, to make a prior art. showing of applicant's claimed technique "wherein said 
operation specifying XML data is parsed after validating said operation specifying XML- 
data to extract at least one identifier for mapping said at least one identifier to an 
available execution process" (see this or similar, but not necessarily identical language in 
the independent claims). 

" tQGSIj Upon receipt, of a configuration file for the device 114 
from the Configuration Server 116, the device validates the 
configuration file by doing a syntax check. In this context, a 

>■ t;U; ,tS)o a u/. -i\ >' (. e e i 1 

cossTjiwmds that are contained in the configuration file. If the 
synt.ax check is successful, then the device 114 applies the 
configuration in formation and writes it: to per si stent, storage 
within the device." (emphasis added) 

As mentioned above, applicant respectfully points out that the excerpts from 
Harvey relied on by the Examiner merely teach that the "Configuration Server 1 16 
retrieves one of the configuration templates 210 that is associated with the device," that 
the "retrieved template is parameterized" and that "a stream or file of XML format 
configuration in ton nation is created and potentially stored" (paragraph [0055]). In 
addition, Harvey also teaches "checking the syntax of the XML text" in order to "[check] 
whether the XML configuration information is valid in comparison to a specified 
Document Type Definition (DTD)" (paragraph [0056]}. Further, Harvey teaches that 
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"the device validates the configuration file by doing a syntax check" which "may involve 
one or more separate checks, including a check of whether the template is well-formed; 
validation of the configuration file; and a syntax check of one or more native commands 
that are contained in the configuration file." 

However, the mere disclosure of retrieving and parameterizing a configuration 
template, creating and storing XML configuration information, and checking the syntax 
of XML text by parsing the XML, in addition to validating the configuration file by doing 
a syntax check, as in Harvey, simply fails to disclose a technique "wherein said operation 
specifying XML data is parsed after validating said operation specifying XML data to 
extract at least one identifier tot .'.mapping said at least one identifier to an available 
execution process" (emphasis added), as claimed by applicant. Clearly, the mere 
disclosure of storing created XML configuration data, as in Harvey, fails to even suggest 
" extractf ing l at least one identifier for mapping said at least one identifier to an available 
execution process" (emphasis added), in the manner as claimed by applicant. 

The Exami ner is reminded that a claim is anticipated only if each and every 
element as set forth in the claim is found, either expressly or inherently described in a 
singl e prior art reference. Verdegaai Bros. v. Union Oil Co. Of California, 814 F.2d 628, 
631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). Moreover, the identical invention must be 
shown in as complete detail as contained in the claim Richardson v. Suzuki Motor 
Co.868 F.2d 1226, 1236, 9USPQ2d 1913, 1920 (Fed. Cir. 1989). The elements must be 
arranged as required by the claim. 

This criterion has simply not been met by the above reference, as noted above. 
Nevertheless, despite such paramount deficiencies and in the spirit of expediting the 
prosecution of the present application, applicant has incorporated the subject matter 
former Claim 91 into the independent claims to further distinguish applicant's claim 
language from the above reference. 
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With respect to the subject matter of former Claim 91 (now at least substantially 
incorporated into the independent claims), the Examiner has relied on paragraphs [005 Ij, 
[0055], and [0056] (cited above) from the Harvey reference to make a prior art showing 
of applicant's claimed "validating said operation specifying XML data received at said 
destination computer against schema data, where said schema data is sent to said 
destination computer from said source computer at the same time as said operation 
specifying XML data" (see this or similar, but not necessarily identical language in the 
independent claims). 

Applicant respectfully points out that the excerpts from Harvey relied on by the 
Examiner merely teach that the "Configuration Server 116 ret > • >ne of the 
con fi gu rati on t em p 1 a te s 210 that is associated with the device" (paragraph [0055] - 
emphasis added). Further, Harvey teaches that "Configuration Server 116 then checks 
whether the XML configuration information is valid in comparison to a s pecified 
Document Type Definition (DTP) that defines a grammar with which the XML 
configuration information must conform" (paragraph [0056] ~ emphasis added). 

However, the mere disclosure that the Configuration Server checks if the retrieved 
configuration template is valid in comparison to a specified Document Type Definition, 
as in Harvey, simply fails to even suggest "validating said operation specifying XML 
data received at said destination computer against schema data, where said >chem utj 
sent to said destination computer from said source computer at the same time as said 
opt'tdtion -| f\ ■ \M lata (emphasis added), as claimed by applicant. Clearly, 
checking configuration information to a specified Document Type Definition, as in 
Harvey, fails to suggest that "said schema data is sent to said destination computer from 
said source computer at the same time as said operation specifying XML data " (emphasis 
added), in the manner as cl aimed by applicant. 



Again, the foregoing anticipation criterion has simply not been met by the above 
reference, as noted above. 
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With respect to the 35 U.S.C. 103(a) rejection of the independent claims, the 
Examiner has relied on paragraphs 0014, 0050, and 0055 from the Uszok reference to 
make a prior art sh i I - que reeeh ng code to receive at 

said destination computer operation specifying XML data sent by said source computer' 
(see this or similar, but not necessarily identical language in the independent claims). 

Applicant respectfully asserts that the excerpts from Uszok relied upon by the 
Examiner discloses a technique where "[tjhe client side-mBot— implements a 
presentation layer, active component oi even [ un XMl or H PM) and mas have 
PW.j tiple presen tati on s for di fferen t pi a tf orm s ' : (Paragraph 0014 - emphasis added). 
However, having the client side implement pure XML simply, as in Uszok, fails to meet a 
"receiving code to receive at said destination computer operation specifyin g XML data 
sent by said source computer ' (emphasis added), as claimed by applicant, 

In the Office Action dated 03/08/2006, the Examiner has further argued that "the 
plug-ins can be passed from the botServer manager to plug-in manager, which is the 
target process" and that "fb]oth managers are performed at the same target computer 
botServer." Additionally, the Examiner cited the following excerpts from Uszok to 
support such assertion. 
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w 10079] Plug- ins: The botServer standard services can be extended 
by a mechanism of plug-ins. A plug-in is a software component 
installed by botServer administrator within the plug-ins manager 
(450) which, communicates with other plug-ins and bots via the 
botServer manager 402 using massages. From the usability point of. 
view, a plug-in is somewhat similar to a hot- -it has an unique 
ID, understands hot messages, participates in protocols etc. A 
plug-in, however, never migrates, cannot be automatically 
downloaded and installed, and usually has much higher system 
security permissions . A plug-in also may possess any number of 
system threads (since it doesn't have to strictly adhere to a 

< i t~ r . i- i T ) t *~ i t " v i fd to 

interface with various external systems, perform demanding real - 

illustrates a plug-in 454 for interfacing with an SAP server 462. 
Another plug-in 452 interfaces with a legacy system 460 such as 
an enterprise database running on a mainframe. FIG. 1? shows 
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Applicant respectfully asserts that the additional excerpts from Uszok relied upon 
by the Examiner simply disclose that "[a] plug-in is a software component installed by 
botServer administrator within the plug-ins manager (450) whicji commum 
other plug-ins and bote via the botServer manager 402 using messages" (emphasis 
added). However., the 'get/set data" and "uses" flows that communicate with the plug-ins 
and hots "using messages" in Uszok's Figure 4 fails to disclose "receiving code to 
receive at said destination computer op€ \ \ < -em h\ said source 

computer" (emphasis added), as claimed by applicant. In addition, Uszok' s disclosure 
that ''"[bjoth managers are erformei the tm< m omputer botServei (emphas- s 
added) simply fails to meet " receiving code to receive at said .destination .computer 
operation specifying XVI L data sent by said >oiuce computer" (emphasis added), as 
claimed by applicant. 



In the Office Action dated 09/22/200o; the Examiner reiterated their previous 
arguments and additionally asserted "Uszok states that data can be exchanged in the 
XML format. . . in the agent based system.'' Additionally, the Examiner cited the 
following excerpts from Uszok to support such assertions. 



"[0065] User Model data are acquired over time by "watching" Che 
user's activities via the GUI 520. Recall that interfaces are 
provided to various user applications such wc;:d processing, 
email, and web browser. The user's actions arc captured as data 
messages and routed by the bot'Kaster core 530 to the Knowledge 

Knowledge of the user ;:ed S a 

conceptual graph, It may be imported from external sources, for 
example using RDF, the Resource Descriptors Framework. RDF is a 

use XML as an interchange syntax." (emphasis added) 



Applicant respectfully notes that the above citation teaches that "the user model 
preferably is stored as a conceptual graph," which "may be imported from external 
souiees. for example using RDF," which "can use XML as an interchange syntax." 
However, teaching that "a conceptual graph . . . may be imported from external sources 
[using] use XML as an interchange syntax" fails to disclose '' receiving code to receive at 
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said destination computer open i spe< f\ ig XML data sent by said source computer" 
(emphasis added), as claimed by applicant. 



In addition, with respect to the independent claims, the Examiner has relied on the 
following excerpt from the Uszok reference to make a prior art showing of applicant's 
claimed "parsing code to parse said operation specifying XML data to identify one or 
more complex data types within said operation specifying XML data" and "matching 
code to match each complex data type with an associated execution process available to 
said destination computer" (see this or similar, but not necessarily identical language in 
the independent claims). 



" r 0 0 5 7 ] Returning now to She bot code acquisition process, the 
botServer 350 may already have .s copy on: ';b.e cos: responding sBot 
class V.or. operation, with the snSot. {Indeed, the hot Server 350 
could even be hosted on the same site as the bet developer site 
310.) If so, the botServer 350 creates an instance of the 
requested sBot and assigns an identifier to it corresponding to 
the mBot that made the request. If th- s ip] c< pj its sCor code is 

sBot code itor& the foot developer site 310 by downlead link 362. 
Authentication of that code, security issues, payment and other 
particulars are discussed later in this description. At the 
botServer, after the sBot is installed, a message originating 
from botMaster 320 is communicated to the sBot code to initialize 
it to carry out the task requested by the user." (Uszok, 
Paragraph 0057 - emphasis added} . 



Applicant respectfully asserts that such excerpt front Uszok relied upon by the 

Examiner merek teaches that the b tServe ; n in in ct _ he requested 

sBot and assigns an identifier to it corresponding to the mBot that made the request" 
(emphasis added). Additionally, Uszok discloses that "fa]t the botServer, after the sBoi is 
installed, a message originating from botMaster 320 is communicated to the sBot code to 
initialize it to carry out the task requested by the user" (emphasis added). However, the 
mere disclosure of creating an sBot. instance and initializing it from "a message 
originating from botMaster" simply, as in Uszok, tails to meet a technique of "parsing 
i ode to pa s eration lying \\1L data to kientif) one or more complex data 

types within said operation specifying XML data" (emphasis added) and " matching code 
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to match each complex data type with an associated execution process available to said 
destination computer' (emphasis added), as claimed by applicant. 



In the Office Action dated 03/08/2006, the Examiner has further argued that 
"Uszok states matching mechanism (0133) and the XML-based interaction protocols 
define a set of states that a bot may exist in, ruies of transiti on from one state to another 
and a description of the schema of data that can be exchanged between participating 
parties in order to transition from one state to another (0128)." Additionally, the 
Examiner cited the following excerpts from Uszok to support such assertion. 



"(01281 A meeting place in the present systas is a separated 
logical area of the botServer, where hots can interact with 
chosen types of ether foots and plug-ins according to defined 
interaction protocols. Interaction, protocols define a set of 
states that a foot:, may exist in, rules of transition from one 
state to another and (optionally] & description of the structure 

(schema) of documents (data) that can be exchanged between 
participating parties in order to transition from one state to 
another. An interaction protocol can be described, for example, 
in an XML-based language. The selected protocols are implemented 
on hot's and plug-ins in accordance with the present invention." 

{Uszok, Paragraph 0128 - emphasis added} . 

The mechanism is abstract, because it does not define what the 
offer really is. The determination is based only on its 
description and applying sophisticated Al algorithms to actually 
perform matching, however XML-based , "hard" — regular expression 
or SQL-like based, matching might be used as well (whioheve ■ more 
useful in a given situation). Such en approach allows, e.g., 
selecting bot.Servers providing most appropriate services, or 
selecting trade offers closest to the buyer's requirements — all 
using the a am* mechanism. Generally the matching service should 
he able to provide a mates of request and offer even if they 
;at it be set ed ! s pie parison,' {Vszi k, Pas jr ;h 
emphasis added; . 



Applicant respectfully asserts that the matching disclosed in the excerpts from 
Uszok relied upon by the Examiner teach that a 'determi nation is based only on its 
description and applying sophisticated Al algorithms to actually perform matching, 
huue^e? \V: > t j " h a rd" --regular expression or SO i -like based, matching might be 
used as weir (emphasis added). However, generally disclosing XML-based matching, as 
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m U'sz-ok, fails to meet "matching code to mate! ta type wild an 

associated execution process available to sa id duqm. hion computer ' (emphasis added), as 
claimed by applicant. Further, Uszok's disclosure where "an interacj^on.pTOtocoj, can be 
described, for example in an > >1 u..l:i u age Mtnph fads to meet ''parsing code to 
parse said operation specifying XMt dau t id en tVj t rec i U. data types 
within said operation specifying XML data" (emphasis added), as claimed by applicant. 



In the Office Action dated 09/22/2006, the Examiner merely reiterated the 
Examiner's previous rejection of applicant's claimed language. Again, applicant 
respectfully notes that none of the language cited by the Examiner teaches "parsing code 
to parse said operation specifying XM L data to identify one or more complex data types 
within said operation specifying XML data" and "matching code to match each complex 
data type with an associated execution process available to said destination computer," as 
specifically claimed by applicant. 



Further, with respect to the independent claims, the Examiner has relied on. the 
following excerpt from the Kouznetsov reference to make a prior art showing of 
applicant's claimed technique "wherein said execution process maps configuration data 
specified within said operation specifying XML data to a configuration data store of said 
destination computer; wherein said configuration data store is one of: a Windows 
Registry entry, an INI file; a DAP! store; and a database entry" (see this or similar, but 
not necessarily identical language in the independent claims). 



effectively an adrainist ta tor tot the reachin.e. An";; gent program 

it < - - - i r- hr? The agent 

includes an application programming interface ("API") for 
receiving requests for privileged processes. The agent includes 
an interface to the privileged process as weir. The agent 
include;? methods for authant: fearing any received request:;; and 
will only forward a request: to the privileged process upon 
determining that the requesting application has sufficient trust. 
Hence, the agent provides a level of indirection in accessing the 
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Briejlij' stated, the peasant invention involves a systeia for 
providing application services in a computing environment having 
both user-mode processes u ri^-r;- • . • j± i oesses. An agent 
s ec'.:t:es in. p.; 1 - 1 i : n L ni ; e 1 user-mods 

processes. A use r-xsiod*;- corapon^nt: is provided with an interface 
configured to access the agent's exposed interface. A 
configuration component specifies a list of installable code 
components that are authorised for installation, wherein the 
agent will only execute privileged-mode functions in response to 
accesses fay the user-mode code component when the installable 
code component is represented on the list ' ! tets Coi, 
lines 25-54 - emphasis added] 



Applicant respectfully asserts that the above excerpt from Kouznetsov relied upon 
by the Examiner teaches that an 'agent includes an application programming interface 
("API") for receiving requests for privileged processes ' (emphasis added). In addition, 
Kouznetsov discloses a " confi gurati on component [which] specifies a list of installable 
code components that a rc authorized for in stal I. ati on, wherein the agent will only execute 
privileged-mode functions in response to accesses by the user-mode code component 
when the installable code component is represented on the list ' (emphasis added). 



However, disclosing an. API with a configuration component, as in Kouznetsov, 
simply fails to meet applicant's claimed technique "wherein said execution process maps 
configuration data specified within said operation specifying. XML data to a 
configuration data store of said destination computer" (emphasis added), in the context 
claimed. In addition, Kouznetsov' s disclosure of "[a] configuration component 
specifying] a list of installable code components" (emphasis added) in no way meets a 
technique "wherein said configuration data store is one of: a Windows Registry entry; an 
INI file; a DAPI store; and a database entry " (emphasis added), as claimed by applicant. 



In the Office Action dated 09/22/2006, the Examiner merely reiterated the 
Examiner's previous rejection of applicant' s claimed language. Again, applicant 
respectfully notes that none of the language cited by the Examiner teaches a technique 
"wherein said execution process maps configuration data specified within said operation 
specifying XM L data to a configuration data store of said destination computer; wherein 
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said configuration data store is one of: a Windows Registry entry; an INI file; a DAPI 
store; and a database entry," as specifically claimed by applicant. 



Additionally, with respect to the independent claims, the Examiner has relied on 
the following excerpt from the Uszok reference to make a prior art showing of applicant's 
claimed technique "wherein an identifier of an execution process within said complex- 
data type includes at least one of: data specifying a computer file to trigger said execution 
process; data specifying a communication channel to trigger said execution process; and 
data specifying an operating system command to trigger said execution process" (see this 
or similar, but not necessarily identical language in the independent claims). 



":0068j Referring again to FIG. 5, establishing a botBox is 
initiated by the user or: prompted by botMaster through the GUI 
520. The GUI command ates via the hotM-astei core 530 to a botBox 
proxy component 54 2. Tho botBox proxy coinponent initializes local 
botBox storage 536 through the botMaster configuration component 
534 and then utilizes a communication manager 544, and more 
specif xcally a botBox communicator component 546, to send a 
message to request initialization of a corresponding botBox on a 
botServer. Any b-ot Server (with botBox facilities) can be used. 

Bets wit i nodest requ t t to th b 1 F < i> hosted 

at more modest bctServers, or even on their own home PC, The user 
can relocate botBox later if desired, and could store it 
{including all bot information; on machine-readable media for 
subsequent uploading on another platform. For commercial 
applications, botBoxes should be housed on & reliable server, 

< U I [ e i pla nn. ?i a v ) - t , ~> 

supports operation of the user's bobs while the uses is off-line, 
and ensures the user's privacy." (Uszok, Paragraph 0068 - 
emphasis added) 



Applicant respectfully asserts that the above excerpt from Uszok relied upon by 
the Examiner discloses that "[f]he botBox proxy component initializes local botBox 
storage 536 through the botMaster configuration component 534 and then utili ■ 
gQMMnj.gMon.ma 

corresponding botBox on abotServer' (emphasis added). However, "sendfjng] a 
message to request initialization of a corresponding botBox," as in Uszok, fails to meet a 
technique "wherein anidentd'^ or u\, i withm said complex data type 

includes at least one of: data specifying a computer file to trigger said execution process; 
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data specifying a communication channel to trigger said execution process; and data 
specifying an operating system command to trigger said execution process" (emphasis 
added), as claimed by applicant. 

In the Office Action dated 09/22/2006, the Examiner relied on the following 
excerpt from the Uszok reference to support the above rejection. 



" r Q 0 5 4 j Importantly, each hot may consist sand usually dees) of 
two - 1 , j , f i " * and 

corresponding mBot component 314. The present invention is not 
limited, however, to foots having a one-to-one relation between 



multiple sBots are mentioned later. Each portion of the bot, mBot 
and sEot, is implemented as a separate executable program 
designed to communicate and interact with its counterpart, We 

call this hi £ uk cation of the bot code. The mBot portion executes 
exclusively on the end user's (client) machine, while the 
corresponding sBot portion executes on a server platform, 

hereinafter called a "bot Server" (350} . To illustrate, taotServer 
is hosting s8ots 352 and 354. The two parts of the bot need not 
necessarily — and frequently do not — execute concurrently. Each 
sBot and the corresponding isihl ing) mBot have knowledge of their 
sibling coiamon globally unique identifier. The m8ot and sBot 
communicate via the hotBox server 360, as explained in detail 
later." (emphasis added) 

* (0064] Pre Lireinari S.y, the botMaster program itself is downloaded 
or otherwise installed on the user platform. To initialize the 
botMaster, the user interacts via the GUI 520 with the botMaster 
core 530 , which in turn communicates with a botMaster 
configuration component 534. « multi-user manager 532 can be 

configuration, user setup data 538 is stored and foot Box storage 

> > „ ItO rt f N> Car 

immediately begin developing the User Modal {532}," {emphasis 
added} 



Applicant respectfully points out that the above excerpts merely disclose that 
'i e jach portion of the bot, mBot and sBot, is implemented as a separate executable 
program" and that "[t jhe mBot portion executes exclusively on the end user's (client) 
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machine." In addition, Uszok teaches that ~[t]o initialize the botMaster, the user interacts 
via the GUI 520 with the botMaster core 530, which in turn communicates with a 
botMaster configuration, component." 



However, implementing mBot as "a separate executable program" and disclosing 
that botMaster is initialized when "the user interacts via the GUI 520 with the botMaster 
core," as in Uszok, simply fails to teach < i s vxithni said 

complex data type " much less a technique "wherein an identifier of an execution process 
within said a ij e> ita type includes at least one of tUt-t ^ ' in puter file to 
trigger said execution process: data speci fy i n g a c pm mun icati on eh a n pel to trigger said 
execution process; and dd | i sten command to trigger said 

execution process" (emphasis added), as claimed by applicant. 



With respect to the independent claims, the Examiner has relied on the following 
excerpt from the Uszok reference to make a prior art showi ng of applicant's claimed 
technique "wherein said result data includes data specifying existing configuration data 
of said destination computer" (see this or similar, but not necessarily identical language 
in the independent claims). 



" v (0122] The user may choose to create the dynamically created, 
teinporary profiles based on existing ones. The temporary profile 

^'-■jt - * v ~ + + ~ - . * n -^.c :ici 

s;er>da.c, anal yzinq the mes saga con;: tsr.it., etc.; and rejected if does 
not fit to the rules defined in the filter. This allows an 
additional anti-spam mechanism to be built into the user. 
- -> i - . " - ~ < i t - > j > 1 r or 

the user account (optionally only notifying it about the 
information rejection;" {'O.stok, Paragraph 0122 - emphasis added; 
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AppHcant respectfully asserts that the excerpt from Uszok above relied upon by 
the Examiner merely teaches that "hjhe user may choose to create the dynamically 
created, temporary profiles based on existing ones.'" However, there simply is no 
mention in the above excerpt of a technique "wherein said result data includes data 
i . rati i data of said destii i > t phasi I 

claimed by applicant. 



In the Office Action dated 09/22/2006, the Examiner responded by stating that 
"[ijn the mBot architecture, the configuration and task results presentation block is 
genereated (0110) and the mBot can send the result back to the sBot (01 1 ) )"' and 
"[tjherefore, Uszok in view of Kouznetsov discloses the limitations in the claims and the 
rejection of the claims are maintained ." Additionally, the Examiner cited the following 
excerpts from Uszok to support such assertions. 



W 10110] FIG. 7 provides a simplified, gene t:,;;}, overview of an xaBot 
architecture. The mBot is also an executable application program, 
designed to interact with one or more related sBot siblings, 
although in most cases interactions will take place via the 
bocBox intermediary. (For some applications, such as those 
requiring near real time >:esu].S:s, direct communication between 
mBot and sBot can be effected using known technologies and 
protocols.! An snBot architecture is centered around an a\8ot logic 
block in a configuration similar to that, of the sBot srchitec^isie 
of FIG. 6. An mBot 700 is, of course, hosted by a botMaster 
application 704. A user control block 706 of the botMaster 
(coupled to the GUI of FIG. 5) allows the user to show or hide 
the mBot "skin." The user control block coiamunicates with a skin 
engine 720. The user can invoke a predetermined configuration for 
the presentation interface, again via the user control block, 
utilizing a "configuration and task results presentation block" 
722. The mBot displays messages, data and other results via the 
results presentation block 722, In c mn ttiort with a botMastet 
presentation space service 724. The mBot utilises a hot data 

1 rage b cl MO or sto; q all neoe saj d i, \ dei ntrol 
of an mBot logic block 702. The mBot: automatically stores and 
loads its data in the botMaster data store, utilizing a botMaster 
* i ? - 712 . ' - v asis added; 

logic block 702. For example, the configuration block 722 can 
receive parameters from the user control block, incorporate them 
and provide them in a call to the logic block 702, The mBot: can 
also send messages to the sBot by utilizing a send-message block 
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740. All messages originating in the send~m.essa.ge block are 

transmitted to the sBot via a botMaster's message service 742. 

BotMaster messa cs services srs descrifatd earl 

refers ce tc r > - . , ges received from the 

sBot (via the botiMast.er message service} are directed to a 

n o; ! ^ t " t tie n But for routing or delivery 

as appropriate. For. example, s.ome iiie.is.ages will ba routed to the 

l > > ^ - o " ^ ~r 1 - 

block 730, for example, to store data in the data block 710 

Applicant respectfully notes that the above excerpts relied on by the Examiner 
merely teach that '[tjhe user can invoke a predetermined configuration for the 
presentati on interface . . . via the user control block.. . utilizing a "configuration and task 
results presentation block 1 ' 722' and that "[tjhe mBot displays messages, data and other 
results via the results presentation block 722" (Paragraph 01 10). Further, Uszok 
discloses that "the configuration block 722 can receive parameters from the user control 
block, incorporate them and provide them in a caii to the logic block 702" (Paragraph 
01 1 1 ). However, displaying "messages, data and other results via the results presentation 

isis added) and i0vc» [mgl parameters from the user control block, 
incorporating] them and proyidf ing] them in a call to the logic block " (emphasis added), 
as in Uszok, clearly does not teach a technique "wherein said result data includes data 
specifying existing configuration data of said destination computer" (emphasis added), as 
claimed by applicant. Clearly, the mere disclosure of receiving parameters from a user 
control block, as in Uszok, simply fails to meet "result data," in the manner as claimed by 
applicant. Further, the disclosure of a user showing or hiding the skin of a botMaster 
hosted mBot, as in Uszok, fails to suggest result data includes data specifying existing 
coMlguration.data of said destination computer " (emphasis added), as claimed by 
applicant 

Further, in the Office Action dated 09/22/2006, the Examiner additionally relied 
on paragraphs [0054] and [0064] from the Uszok reference ('reproduced above) to support 
their above rejection. As previously mentioned, applicant, respectfully points out that the 
above excerpts merely disclose that "|>]aeh portion of the hot, mBot and sBot, is 
implemented as a separate executable program" and that "[tjhe mBot portion executes 
exclusively on the end user's (client) machine" (paragraph [0054]) Further, Uszok. 
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teaches that *'[t]o initialize the botMaster, the user interacts via the GUI 520 with the 
botMaster core 530, which in turn communicates with a botMaster configuration 
component " and that "[i jn botMaster configuration, user setup data 538 is stored" 
t : i raph [0064] - emphasis added). 



However, disclosing that a botMaster core "communicates with a botMaster 
configuration component" (emphasis added}., as in Uszok, simply does not teach "result 
data," much less a technique "wherein said result data includes data specifying existing 
configuration data of said destination computer (emphasis added), as claimed by 
applicant. 



With respect to the independent claims, the Examiner has relied on the following 
excerpt from the Uszok reference to make a prior art showing of applicant's claimed 
technique "wherein said execution process maps existing configuration data of said 
destination computer stored within said configuration data store of said destination 
computer to said result data to be returned to said source computer" (see this or similar, 
but not necessarily identical language in the independent claims). 



* 1 0100] FIG. 11-8 illustrates a master-slave arrangement for 
shading a foobBox, Here, trie user- ins; Ls I i s a botMaster application 
1118 on a portable device such as a PDA, ceil phone, or 
automobile Internet appliance . "'his may be a "thin client" with a 
simplified user interface (perhaps with limited graphics), and it 
may lack the software and memory necessary for creating and 
maintaining a user model . 

botMaster 1110. The portable botMaster, in a slave mode, employs 
the user model maintained by the master botMaster 1110 and the 
portable program assigns to its roBots one of the user profiles 
made available on the shared botBox 1112. Creating new profiles 



Applicant respectfully asserts that the excerpt from Uszok. above relied upon by 
the Examiner teaches that "(t]he portable botMaster, in a slave mode, employs the user 
model maintained by the master botMaster ! 1 10 and the portable program assigns to its 



emphasis added) 
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Botsjme oi er.pn ilk iade a on the :>h;?u\l bot \ { phasi 

added) since "it may lack, the software and memory necessary for creating and 
fflajntj&mn^ (emphasis added). The disclosure of "employ png] the user 

model maintained by the master botMaster," as in Uszok, simply fails to even suggest a 
technique "wherein said execution process maps existing covvfigurath o data of said 
destination computer stored within said configuration data store of said destination 

imputer i sujt data f< et ed J »d..soiace < « ' i npi ^ addt 

claimed by applicant. 



In the Office Action dated 09/22/2006, the Examiner responded by arguing that 
"[i]n the mBot architecture, the configuration and task results presentation block is 
genereated (01 10) and the mBot can send the result back to the sBot. (01 1 1)." 

configuring a required logics! function to be- carried cut by the 
logic block 702. for example, the configuration block 722 can 

and provide them in a call to the logic block 702. The mBot can 
also send messages to the sBot by utilizing a send-message block 
740. All raesssges originating in the s end-mas sags block sre 
transmitted to the sBot via a botMaster ' s message service 742, 
BotMastec messaging services were described earlier with 
reference to FIG. 5. Conversely, all messages received from the 
sBot (via the botdaster message service} are directed to a 
massage dispatcher block 730 in the mBot: for routing or delivery 
as appropria i:e . For ecasuple, some me;; sages will be routed to the 
logic block while others might invoke methods in a dispatcher 
block 730, for example, to store data in the data block 710 

Applicant respectfully points out that the above excerpts merely disclose that 
lllhejnta utilizing a send-message block" 

(emphasis added) in addition to teaching that '[tjhe user can invoke a predetermined 
configuration for die presentation interface. . . via the user control block. . . utilizing a 
"configuration and task results p« ■ lock ; id that "[t]he mBot displays 
messages, data and other results via the results presentation block 722" (paragraph 
(01 10]) as mentioned above. However, sending messages from the mBot to the sBot, in 
addition to dispk i| messages utilizing a "configuration and task results presentation 
block" fails to teach a technique "wherein said execution process maps existing 
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a < ^ data of said destination computer stored within said configuration data 
store of said destination computer to said result data to be returned to said source 
computer" (emphasis added), as claimed by applicant 

In the Office Action dated 09/22/2006, the Examiner additionally relied on 
paragraphs [0054] and [0064] from the Uszok reference (reproduced above) to support 
their above rejection. As previously mentioned, applicant respectfully points out that the 
above excerpts merely disclose that "[e]ach portion of the hot, mBot and sBot, is 
implemented as a separate executable program" and that % '[t]he mBot portion executes 
exclusively on the end user's (client) machine'" (paragraph [0054]) Further, Uszok 
teaches that "[t]o initialize the botMaster, the user interacts via the GUI 520 with the 
botMaster core 530, which in turn communicates with a botMaster con figuration 
component " and that "fi]n botMaster configuration, user setup data 538 is stored" 
(paragraph [0064] - emphasis added). However, the mere disclosure that the user 
interacts via the GUI with the botMaster core which communicates with a botMaster 
configuration component, as in Uszok, simply fails to even suggest a technique "wherein 
said execution process maps existing configuration data of said destination computer 
stored within said configuration data store of said destination computer to said result data 
to be returned to said source, computer (emphasis added), as claimed by applicant. 

With respect to the independent claims, the Examiner has relied on paragraphs 
[0054] and [0064] from the Uszok reference (reproduced above) to make a prior art 
showing of applicant' s claimed technique "wherein said operation specifying XML data 
is parsed after validating said operation specifying XML data to extract at least one 
identifier for mapping said at least one identifier to an available execution process" and a 
technique "wherein said operation specifying XML data includes parameter data used by 
said execution process in said operation" (see this or similar, but not necessarily identical 
language in the independent claims). 

As previously mentioned, applicant respectfully points out that the above excerpts 
merely disclose that "[ejach portion of the bot, mBot and sBot, is implemented as a 
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separate executable program" and that "[tjhe mBot portion executes exclusively on the 
end user's (client) machine" (paragraph [0054]) Further, Uszok discloses that "(tjo 
initialize the botMaster, the user interacts via the GUI 520 with the botMaster core 530, 
which in turn communicate- a ith i o M i iter confi gu rati on component'" and that u [i]n 
botMaster configuration, user setup data 538 is stored'" (paragraph [0064] - emphasis 
added). However, mere disclosure that the user interacts via the GUI with the boMaster 
core with communicates with a botMaster configuration component, as in Uszok, simply 
fails to even suggest a technique "wherein said operation specifying XML data is parsed 
after validating said operation specifying XML data to extract at least one identifier for 
mapping said at least one identifier to an available execution process" and a technique 
"wherein said operation specifying XM1 data includes pa u * da i idhvsaul 
execution process in said operation'" (emphasis added), as claimed by applicant. 

To establish n prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves or 
in the knowledge generally a vailable to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both be found in the 
prior art and not based on applicant's disclosure. In re Vaeck,941 F.2d 488, 20 USPQ2d 
1438 (Fed.Gr. 1991). 

Applicant respectfully asserts that at least the third element of the prima facie 
case of obviousness has not been met, since the prior art references, when combined, fail 
to teach or suggest aj| of the claim limitations, as noted above. Nevertheless, despite 
such paramount deficiencies and in the spirit of expediting the prosecution of the present, 
application, applicant has incorporated the subject matter of former Claim 91 into the 
independent claims. 
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With respect to the subject matter of former Claim 91 (now at least substantially 
incorporated into the independent claims), the Examiner has relied on the Paragraphs 
0051, 0055, and 0056 (reproduced above) from the Uszok reference to make a prior art 
showing of applicant's claimed "validating said operation specifying XML data received 
at said destination computer against schema data, where said schema data is sent to said 
destination computer from said source computer at the same time as said operation 
specifying XM L data" (see this or similar, but not necessarily identical language in the 
independent claims). 

Applicant respectfully asserts that the excerpts from Uszok relied upon by the 
Examiner merely disclose that "[a] number of formal systems have been proposed for 
expressing t n forms that are useful for computers to exchange and acquire 

knowledge" where "fsjome of the leading protocols include KIF (Knowledge Interchange 
Format)" (Paragraph 0051). Further, Uszok discloses that "(wjithin this environment, 
hots can acquire and exchange knowledge using virtually any desired language, 
metalanguage or ontology'' (Paragraph 005 1 ). In addition, Uszok discloses that "[e]ach 
portion of the hot, mBot and sBot, is implemented as a separate executable program 
designed to communicate and interact with its counterpart" where '[t]he mBot portion 
executes exclusively on the end user's (cli ent) machine, while the corresponding sBot 
portion executes on a server platform , hereinafter called a "botServer" (350)' and "[tjhe 
mBot and sBot communicate via the botBox server 360" (Paragraph 0054 - emphasis 
added)- In addition, Uszok discloses that *'[w]hen the user deploys the hot. . . a launch 
message is sent ft on b< A\ ei to the serve} (more precisely --to botBox) to launch the 
corresponding sBot" (Paragraph 0056 - em pita sis added). 

However, the mere disclosure of using a KIF format for computers to exchange 
information, that the mBot executes on the client machine, and the sBot executes on the 
botServer, where a user deployed hot sends a launch message to the botServer to launch 
the sBot. as in Uszok, simph tails to suggest validating said opei iti 1 1 ip< Mung XML 
data received at said destination computer against schema data, where said schema data is 
sent to said destination computer from said source computer at the same time as said 
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opet ation sp<. S i I data " (emphasis added), as claimed by applicant. Clearly, the 

disclosure that computers communicate via K1F, as in Uszok, tails to suggest that "said 
sdlgA?)l..data.i.s .sept to said destination computer from said source computer at the .same 
time as said operation specifying XML data" (emphasis added), in the manner as claimed 
by applicant 

Further, applicant has considered the Uszok reference in it's entirety, and 
respectfully asserts that paragraph 0128 in Uszok merely discloses that "[a] meeting place 
in thepicsem sNst^ni is .1 st_, i ijogu it' tServei where hots tan mteuU 
with chosen types of other hots and plug-ins accor di n g to de.fi n ed i n tera ct i on .protocol s ' ' 
(Paragraph 0128 - emphasis added). Further, Uszok discloses that "[ijnteraction 
protocols define a set of states that a hot may exist in, rules of transition from one state to 
another and [optionally] a descripti on of the structure (schema) of documents (data) that 
can be .exchanged between participating parties in order to transition from one stale to 
another" where "[a]n interaction protocol can be described, for example, in an XM.L- 
basej igtf (Paragraph 0128 - emphasis added). 

However, the mere disclosure of a se parated logical area of the botServer where 
hots interact according to defined interaction protocols with may optionally define a 
schema of documents that may be exchanged between participating parties, as in Uszok, 
simply fails to suggest that said schet > d ^ sent to said destination computer from 
said source computer at the same time as said operation specifying XML data " (emphasis 
added), in the manner as claimed by applicant. Clearly, Uszok's interaction protocols 
occur in a separated logical area of the botServer , which fails to suggest that "said 
schema data is sent to said destination computer from sai • rce computer '" (emphasis 
added), in the manner as claimed by applicant 

Additionally, applicant has considered the Uszok reference in it's entirety, and 
applicant respectfully asserts that paragraph 0129 in Uszok merely discloses that "[a] hot 
developer kit (SDK) can be arranged to generate hot code to implement any of a selection 
of predetermined protocols" (Paragraph 0129 - emphasis added). Further, Uszok 
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discloses that "[t]hrough this implementation of protocols and si i< • ta schema, 
Mitt, t" ab tit; if bots is en; bled ox er a wide variety of practical applications" where 
"[a] Bot platform (botServer/hotExecutor) . . . excludes from interaction those bots that do 
not conform to the agreed protocol" (Paragraph 0129 -- emphasis added). 

Clearly, Uszok's disclosure of using a selection of predetermined protocols and 
standard ci ita scfieni i to enable in|.e.!.ope? ibilil oj >ot§ md to exclude bots that do not 
conform to the agreed protocol simply fails to even suggest that "said schema data is sent 
to said destination compute) from said source ( omputei anhc tm turn as said opei ition 
specifying XML data " (emphasis added), in the manner as claimed by applicant. 
Furthermore, Uszok's teachings of using a standard schema to enable interoperability of 
bots actually reaches away from applicant's claimed sending "said schema. data ...to said 
destination computer from said source computer at the same time as said operation 
spec i tying XML data " (emphasis added), in the manner as claimed by applicant; since the 
bots would already be utilizing the standard schema to ensure interoperability among die 
bots. 

Again, applicant respectfully asserts that at least the third element of the prima 
facie case of obviousness has not been met, since the prior art references, when 
combined, fail to teach or suggest all of the claim limitations, as noted above. 

Thus, a notice of allowance or specific prior art showing of each of the foregoing 
claim elements, in combination with the remaining claimed features, is respectfully 
requested. 

Still yet, applicant brings to the Examiner's attention the subject matter of new 
Claims 95-98 below, which are added for full consideration: 

"wherein said validating of said operation specifying XML data and said 
schema data transmitted from said source computer to said destination computer 
at the same time generates a validation result" (see Claim 95); 
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"wherein said validation result triggers at least one of a valid configuration 
response and ail invalid configuration response" (see Claim 96); 

"wherein said invalid configuration response generates an error message 4 
(see Claim 97); and 

"wherein said valid configuration response starts execution of an 
associated computer program" (see Claim 98). 

Thus, all of the independent claims are deemed allowable. Moreover, the 
remaining dependent claims are further deemed allowable, in view of their dependence 
on such independent claims. 

In the event a telephone conversation would expedite the prosecution of thi s 
application, the Examiner may reach the undersigned at (408) 505-5100. The 
Commissioner is authorized to charge any additional fees or credit any overpayment to 
Deposit Account No. 50-1351 (Order No. NAM.P480/0 1,298.01). 

Re spectful ! y s u b m i tted , 
Zilka-Kotab, PC. 

/KEV1NZ1LKA/ 

Kevin J. Zilka 

P.O. Box 721 1 20 Registration No. 41,429 

San Jose, CA 95 1 72-1120 
408-505-51 00 



